abs is useful enough that you should just put it on the Float trait in src/float/mod.rs honestly, we use it everywhere (e..g.

This should get something in testcrate/tests, and a call in examples/intrinsics.rs to make sure either linking or a fallback works (I think you can just call the intrinsic here since the API isn't in core).

Also we do have this symbol in libm (excluding the f128 version), it just isn't exposed (though we would like it to be). It seems fine to have it here until the libm situation improves somewhat, but I think this would be the first symbol that isn't part of compiler-rt.

I'll still defer to @Amanieu to confirm that though

The evolution of this is my determination that we don't need it in llvm/llvm-project#111269

Is it possible we might need copysign to support gcc-generated code? This may be need for musl targets where we ship a gcc-compiled musl.

As copysign/copysignf are part of libm, musl provides it's own implementation, so that shouldn't be an issue for musl targets.

We could probably make adjustments so that we can expose only specific functions from our libm on all platforms, then do so for the symbols here rather than duplicating them in builtins. Instead of the current all-or-nothing libm. (I think we might want this in the future anyway)

Is it possible we might need copysign to support gcc-generated code? This may be need for musl targets where we ship a gcc-compiled musl.

this feels unlikely as there was no situation in which LLVM generated copysign for a type that we also use. if gcc generates that much worse code, then I suggest we file a compiler bug.